now maybe fixes #2444 ,

at least my Mobvoi Health going to pair screen (after TOS)

but code in rough state for now

now, my device is trying to pair via Mobvoi Health

now need to implement openChannel method (wip)

for now only rfcomm client supported

ble, network, server is not implemented

@deadYokai
Please look at the errors here: https://github.com/microg/GmsCore/actions/runs/20686657931?pr=3204

@ale5000-git as i mentioned before

After 465f5f0 requires merging PR microg/Wearable#3 and pushing to maven

or i can try to move https://github.com/microg/Wearable/ into GmsCore repo and get rid of dependence

https://mvnrepository.com/artifact/org.microg/wearable/0.1.1

Sorry I missed that point, then we have to wait for @mar-v-in for the decision of this thing.
In the meanwhile go ahead with the other parts you are working, thanks.

I'd suggest to entirely move the content of the microg/Wearable repo into play-services-wearable/core module in this repo and then we can archive the microg/Wearable repo entirely.

just sharing with good looking logs, in my opinion (logcat)

P.s. still not paired yet

i cannot pinpoint why connection closing when channel tries to open

can anybody help me? like some logs maybe logs from watch (i cannot capture from my)?

Just looked at your code quickly, and you're the first who even got the Bluetooth UUID right. Looks very promising, keep it up. 👍

I'll try to test your code, as soon as I can with my Pixel Watch.

EDIT: If you need more information about the protocol, hit me up. I'm happy to help :)

Yes, almost. I think the last two commits are not needed. The revert commit is definitely not needed, as the commit it reverts does not exist in the history anymore.

I'm not sure what Clean history does. Did you make any changes after node migration update?

If not, try git reset HEAD~2 --hard. This removes the last two commits from the history completely and resets your working directory to node migration update. This will require a force push

Also, I'm sorry for causing all this trouble. I hope this is ok for you…

its ok, i just not good at git

Edit: maybe i need take courses on git

its ok, i just not good at git

That is totally fine. Thanks a bunch for doing the work anyway! Also, if you need help, I'm glad to help. I only learned a lot of my git skills because a friend showed me recently :)

@teccheck check if this makes sense

https://pastebin.com/KKDJtd4y

@teccheck can you check proto communication in last commit?

@teccheck can you check proto communication in last commit?

I have a few exams coming up, so I don't have that much time rn.

But I took a quick look at this anyway, and there are a few errors:

• ChannelTransferInfo: This is an incorrect and renamed version of ChannelDataHeader
• ChannelTransferRequest: Renamed version of ChannelDataRequest
• ChannelCloseRequest: Renamed version of ChannelDataAckRequest
• ChannelRequest: the sub message types changed to the ones above, status_code and error_code should stay origin and minVersion
• FetchAsset: was correct before, field names are wrong now
• FilePiece: was correct before, field names are wrong now

However, you did get some things right:

• Using Enums is a good idea, and I've tested that, but there seems to be a problem with them (Maybe it's a problem with Wire, the protobuf lib we're using. When I use them, the decoding is messed up
• Connect mostly looks good to me

Please don't take this personal, but did you use some AI to generate that? I'm asking because a lot of this seems quite messy. All the renaming of things that worked perfectly fine before seems like a human wouldn't do that without thinking twice about it. Especially because these names were established before and they don't come out of nowhere…

So I checked GMS again and made some changes to wearable.proto. I will test them later or tomorrow and commit them once they're ready.

some AI to generate that
these names were established before and they don't come out of nowhere…

i used for reconstructing proto file from gms code

Edit: maybe i going to revert last 2 commits

some AI to generate that
these names were established before and they don't come out of nowhere…

i used for reconstructing proto file from gms code

Edit: maybe i going to revert last 2 commits

No worries and don't revert them just yet ;)
EDIT: Never mind, it's fine :D

From a quick look, I think you should at least keep WearableReader and WearableWriter. And maybe move NetworkConnectionX into their own package, as I don't think bluetooth is quite right here.

some AI to generate that
these names were established before and they don't come out of nowhere…

i used for reconstructing proto file from gms code
Edit: maybe i going to revert last 2 commits

No worries and don't revert them just yet ;) EDIT: Never mind, it's fine :D

From a quick look, I think you should at least keep WearableReader and WearableWriter. And maybe move NetworkConnectionX into their own package, as I don't think bluetooth is quite right here.

because of this i commited revert, instead of rebasing

In general, you might want to keep your commits small. That way you can only revert specific things. For example, you could make a commit for just WearableReader and WearableWriter. I'm sure, you'll get the hang of it. Keep at it 👍

I've committed a few things to my branch. Please don't include them into your branch yet. I'll try to incorporate the good changes from 65a1e42

I've added 3 commits to my branch containing all of your changes unrelated to proto. Feel free to take a look. If you want to cleanly include them in your branch, you can do so via git reset --hard HEAD~3 and git pull [remote name of my repo] wearable. Cheers :D

I just noticed, that I made a mistake with the ChannelControl Type in proto. They should be:

CHANNEL_CONTROL_OPEN = 1;
CHANNEL_CONTROL_OPEN_ACK = 2;
CHANNEL_CONTROL_CLOSE = 3;

This was correct in the constants in ChannelManager, but with your last two commits that changed.

I just noticed, that I made a mistake with the ChannelControl Type in proto. They should be:

CHANNEL_CONTROL_OPEN = 1;
CHANNEL_CONTROL_OPEN_ACK = 2;
CHANNEL_CONTROL_CLOSE = 3;

This was correct in the constants in ChannelManager, but with your last two commits that changed.